Video processing system using ring buffer and racing-mode ring buffer access control scheme

ABSTRACT

A video processing system has a storage device, an audio/video demultiplexing circuit, and a video decoder. The storage device has a bitstream buffer that is a ring buffer. The audio/video demultiplexing circuit receives an input data, and performs an audio/video demultiplexing operation upon the input data to write data of a video bitstream into the ring buffer. The video decoder fetches data of the video bitstream from the ring buffer, and performs a video decoding operation upon the fetched data of the video bitstream.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional application No.62/361,091, filed on Jul. 12, 2016 and incorporated herein by reference.

BACKGROUND

The disclosed embodiments of the present invention relate to video dataprocessing, and more particularly, to a video processing system using aring buffer and a racing-mode ring buffer access control scheme.

One conventional video system design may include a video transmittingsystem (which may serve as a video recording system) and a videoreceiving system (which may serve as a video playback system). Regardingthe video transmitting system, it may be composed of a plurality ofprocessing stages, including a video encoder, an audio/videomultiplexing circuit, a transmitting circuit, etc. Regarding the videoreceiving system, it may be composed of a plurality of processingstages, including a receiving circuit, an audio/video demultiplexingcircuit, a video decoder, a display engine, etc. However, theconventional video system design may fail to meet the requirements ofsome ultra-low latency applications due to long playback latency at thevideo receiving system. Hence, there is a need for an innovativelow-latency and high-performance video receiving system.

SUMMARY

In accordance with exemplary embodiments of the present invention, avideo processing system using a ring buffer and a racing-mode ringbuffer access control scheme is proposed to solve the above-mentionedproblem.

According to a first aspect of the present invention, an exemplary videoprocessing system is disclosed. The exemplary video processing systemincludes a storage device, an audio/video demultiplexing circuit, and avideo decoder. The storage device has a bitstream buffer that is a ringbuffer. The audio/video demultiplexing circuit is arranged to receive aninput data, and perform an audio/video demultiplexing operation upon theinput data to write data of a video bitstream into the ring buffer. Thevideo decoder is arranged to fetch data of the video bitstream from thering buffer, and perform a video decoding operation upon the fetcheddata of the video bitstream.

According to a second aspect of the present invention, an exemplaryvideo processing system is disclosed. The exemplary video processingsystem includes a storage device, a video decoder, and a display engine.The storage device includes a display buffer that is a ring buffer. Thevideo decoder is arranged to perform a video decoding operation upondata of a video bitstream to write pixel data of a reconstructed videoframe into the ring buffer. The display engine is arranged to fetchpixel data of the reconstructed video frame from the ring buffer, anddrive a display device according to the fetched pixel data of thereconstructed video frame.

According to a third aspect of the present invention, an exemplary videoprocessing system is disclosed. The exemplary video processing systemincludes a storage device, a receiving circuit, and an audio/videodemultiplexing circuit. The storage device includes a data buffer thatis a ring buffer. The receiving circuit is arranged to receive packetsand unpack the packets to write payload data of the packets into thering buffer. The audio/video demultiplexing circuit is arranged to fetchan input data from the ring buffer, and perform an audio/videodemultiplexing operation upon the fetched input data, wherein thefetched input data comprise payload data of at least one of the packets.

These and other objectives of the present invention will no doubt becomeobvious to those of ordinary skill in the art after reading thefollowing detailed description of the preferred embodiment that isillustrated in the various figures and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a video receiving systemaccording to an embodiment of the present invention.

FIG. 2 is a diagram illustrating a first video processing systemaccording to an embodiment of the present invention.

FIG. 3 is a diagram illustrating a bitstream buffer implemented using aring buffer according to an embodiment of the present invention.

FIG. 4 is a flowchart illustrating a method of controlling a writeoperation of a bitstream buffer according to an embodiment of thepresent invention.

FIG. 5 is a flowchart illustrating a method of controlling a readoperation of a bitstream buffer according to an embodiment of thepresent invention.

FIG. 6 is a diagram illustrating a second video processing systemaccording to an embodiment of the present invention.

FIG. 7 is a diagram illustrating a display buffer implemented using aring buffer according to an embodiment of the present invention.

FIG. 8 is a flowchart illustrating a display control method according toan embodiment of the present invention.

FIG. 9 is a diagram illustrating a third video processing systemaccording to an embodiment of the present invention.

FIG. 10 is a diagram illustrating a data buffer implemented using a ringbuffer according to an embodiment of the present invention.

FIG. 11 is a flowchart illustrating a method of controlling a writeoperation of a data buffer according to an embodiment of the presentinvention.

FIG. 12 is a flowchart illustrating a method of controlling a readoperation of a data buffer according to an embodiment of the presentinvention.

FIG. 13 is a diagram illustrating a frame base address switching circuitaccording to an embodiment of the present invention.

FIG. 14 is a diagram illustrating a video frame displayed on a displaydevice according to an embodiment of the present invention.

DETAILED DESCRIPTION

Certain terms are used throughout the description and following claimsto refer to particular components. As one skilled in the art willappreciate, manufacturers may refer to a component by different names.This document does not intend to distinguish between components thatdiffer in name but not function. In the following description and in theclaims, the terms “include” and “comprise” are used in an open-endedfashion, and thus should be interpreted to mean “include, but notlimited to . . . ”. Also, the term “couple” is intended to mean eitheran indirect or direct electrical connection. Accordingly, if one deviceis electrically connected to another device, that connection may bethrough a direct electrical connection, or through an indirectelectrical connection via other devices and connections.

FIG. 1 is a block diagram illustrating a video receiving systemaccording to an embodiment of the present invention. The video receivingsystem 120 communicates with a video transmitting system 100 via acommunication link 110. Byway of example, but not imitation, the videotransmitting system 100 and the video receiving system 120 may beemployed by an ultra-low latency application such as a virtual reality(VR) application. In this embodiment, the video receiving system 120includes a receiving (RX) circuit 112, a storage device 124, anaudio/video demultiplexing circuit (denoted by “A/V DEMUX”) 126, a videodecoder (denoted by “VDEC”) 128, a display engine 130, and a displaycontrol circuit 132. The storage device 124 includes a data buffer 134,a bitstream buffer 136, a display buffer 138, and a reference framebuffer 139.

The video transmitting system 100 may serve as a video recording systemthat is used to encode video frames provided from one or more videosources (not shown) and then transmit encoded video data to the videoreceiving system 120 via the communication link 110. The video receivingsystem 120 may serve as a video playback system that is used to receiveencode video frame data from the communication link 110 and then decodethe encoded video frame data to generate reconstructed video frames to adisplay device 140 for video playback. For example, the display device140 may be a display screen of a VR headset. In addition, thecommunication link 110 may be implemented using a wired communicationlink or a wireless communication link.

The receiving circuit 122 receives packets from the communication link110, and unpacks the packets to write payload data of the packets intothe data buffer 134. The payload data of the packets may include encodedvideo data, encoded audio data and other user defined data. Theaudio/video demultiplexing circuit 126 fetches an input data from thedata buffer 134, and performs an audio/video demultiplexing operationupon the fetched input data, where the fetched input data may includepayload data of at least one of the packets received by the receivingcircuit 122. Due to audio/video demultiplexing, a video bitstream and anaudio bitstream are separated and forwarded to the bitstream buffer 136and the audio data path 133, respectively. In other words, theaudio/video demultiplexing circuit 126 performs the audio/videodemultiplexing operation upon the fetched input data to write data of avideo bitstream into the bitstream buffer 136 and supply data of anaudio bitstream to the audio data path 133. The audio bitstream isdecoded by the audio data path 134 to obtain audio data for audioplayback. Regarding the video processing and playback, the video decoder128 fetches data of the video bitstream from the bitstream buffer 136,and performs a video decoding operation upon the fetched data of thevideo bitstream to write pixel data of a reconstructed video frame intothe display buffer 138.

A coding block in a video frame may be encoded using an intra predictionmode or an inter prediction mode. When a coding block in a current videoframe is encoded using the inter prediction mode, a predicted block usedto reconstruct the coding block of the current video frame is found in areference frame which is a previously reconstructed video frame andstored in the reference frame buffer 139. Hence, a reconstructed videoframe generated from decoding a previous video frame by the videodecoder 128 is further stored in the reference frame buffer 139 to serveas a reference frame that may be used to decode a current video frame.

The display engine 130 is a driving circuit controlled by the displaycontrol circuit 132. The display engine 130 fetches pixel data of thereconstructed video frame from the display buffer 138, and drives thedisplay device 140 according to the fetched pixel data of thereconstructed video frame.

In this embodiment, the storage device 124 may be implemented using aninternal storage device, an external storage device, or a combination ofan internal storage device and an external storage device. For example,the internal storage device may be a static random access memory (SRAM)or may be flip-flops; and the external storage device may be a dynamicrandom access memory (DRAM) or may be a flash memory.

Since different processing stages in the video receiving system 120 mayhave different data processing rates, one buffer is coupled betweendifferent processing stages. As shown in FIG. 1, the data buffer 134 iscoupled between the preceding receiving circuit 122 and the followingaudio/video demultiplexing circuit 126, the bitstream buffer 136 iscoupled between the preceding audio/video demultiplexing circuit 126 andthe following video decoder 128, and the display buffer 138 is coupledbetween the preceding video decoder 128 and the following display engine130. If one buffer coupled between different processing stages withdifferent data processing rates is implemented using a small-sizedbuffer, the small-sized buffer may suffer from underflow or overflowduring processing of one video frame. This may lead to extra accesslatency. If one buffer coupled between different processing stages withdifferent data processing rates is implemented using a large-sizedbuffer, the large-sized buffer may avoid underflow and overflow duringprocessing of one video frame at the expense of the buffer cost. In thisembodiment, at least one of data buffer 134, bitstream buffer 136, anddisplay buffer 138 may be implemented using a ring buffer. Due toinherent characteristics of a ring buffer, a storage space of asmall-sized ring buffer can be reused, such that the small-sized ringbuffer may act as a large-sized buffer. In addition, a racing-mode ringbuffer access control scheme may be employed to prevent a followingprocessing stage from retrieving wrong data from the ring buffer and/orprevent a preceding processing stage from overwriting buffered data thatis not processed by the following processing stage yet. To put itsimply, the present invention proposes using a ring buffer betweendifferent processing stages in a video receiving system for achieving abalance between the access latency and the buffer cost.

FIG. 2 is a diagram illustrating a first video processing systemaccording to an embodiment of the present invention. The videoprocessing system 200 may be a part of the video receiving system 120shown in FIG. 1. In this embodiment, the video processing system 200includes the audio/video demultiplexing circuit 126, the video decoder128, and the bitstream buffer 136. In addition, the bitstream buffer 136is implemented using a ring buffer as shown in FIG. 3. Further, aracing-mode ring buffer access control scheme is employed to prevent thevideo decoder 128 from retrieving wrong data from the ring buffer (i.e.,bitstream buffer 136), and prevent the audio/video demultiplexingcircuit 126 from overwriting buffered data that is not processed by thevideo decoder 128 yet.

As shown in FIG. 3, the bitstream buffer 136 is a ring buffer having atop address v_start and a bottom address v_end. In one embodiment, thetop address v_start and the bottom address v_end may be physicaladdresses that define a continuous physical storage space. In anotherembodiment, the top address v_start and the bottom address v_end may bevirtual addresses that define a continuous logical storage space. Hence,the total bitstream buffer size is equal to (v_start−v_end). Thebitstream buffer 136 can be accessed (read/written) in a direction fromthe top address v_start to the bottom address v_end and then rollingback to the top address v_start from the bottom address v_end.

During audio/video demultiplexing of an input data (which containsencoded video data and encoded audio data) of one video frame, theaudio/video demultiplexing circuit 126 writes data of a video bitstreaminto the bitstream buffer 136, such that a write pointer wptr (which isindicative of a current write address of writing data of the videobitstream into the bitstream buffer 136) moves downwards. Specifically,the audio/video demultiplexing circuit 126 analyzes the input data(which contains encoded video data and encoded audio data), and writesdata of a video bitstream into the bitstream buffer 136. Hence, theaudio/video demultiplexing circuit 126 updates the write pointer wptraccording to the size of video data stored into the bitstream buffer136. When the write pointer wptr reaches the bottom address v_end, thewrite pointer wptr will roll back to the top address v_start, such thatwriting data of the video bitstream into the bitstream buffer 136continues seamlessly.

During video decoding of a video bitstream of one video frame, the videodecoder 128 reads data of the video bitstream from the bitstream buffer136, such that a read pointer rptr (which is indicative of a currentread address of reading data of the video bitstream from the bitstreambuffer 136) moves downwards. When the read pointer rptr reaches thebottom address v_end, the read pointer wptr will roll back to the topaddress v_start, such that reading data of the video bitstream from thebitstream buffer 136 continues seamlessly.

After an old data segment stored in the bitstream buffer 136 is read andprocessed by the video decoder 128, a storage area which buffers the olddata segment can be reused to buffer a new data segment generated fromthe audio/video demultiplexing circuit 126. In addition, after the olddata segment (which has been read and processed by the video decoder128) is overwritten by the new data segment generated from theaudio/video demultiplexing circuit 126, the storage area can be read bythe video decoder 128 again to obtain the new data segment. Due toinherent characteristics of the ring buffer, the write pointer wptrchases the read pointer rptr, and the read pointer rptr also chases thewrite pointer wptr. A racing mode between the read pointer rptr and thewrite pointer wptr may be employed to control access (read/write) of thebitstream buffer 136 that is a ring buffer. In accordance with theracing-mode ring buffer access control scheme, the audio/videodemultiplexing circuit 126 is configured to include a write controller202 which updates the write pointer wptr to the video decoder 128, andthe video decoder 128 is configured to include a read controller 204which updates the read pointer rptr to the audio/video demultiplexingcircuit 126.

FIG. 4 is a flowchart illustrating a method of controlling a writeoperation of the bitstream buffer 136 according to an embodiment of thepresent invention. Provided that the result is substantially the same,the steps are not required to be executed in the exact order shown inFIG. 4. The method shown in FIG. 4 may be employed by the writecontroller 202. At step 402, the write controller 202 sets an initialstart point position, wherein a start point is indicative of a startaddress of a video bitstream stored in the bitstream buffer 136 by theaudio/video demultiplexing circuit 126. Since the bitstream buffer 136is a ring buffer, the initial start point position is set by an addressbetween the top address v_start and the bottom address v_end. Inaddition, at the beginning of writing data of the video bitstream intothe bitstream buffer 136, a first data segment of the video bitstream iswritten into a memory word addressed by a write address that is theinitial start point position.

At step 404, the write controller 202 compares its write pointer wptrwith the received read pointer rptr to check if a distance between thewrite pointer wptr and the read pointer rptr does not reach a threshold(e.g., wptr !=rptr−1). When the distance between the write pointer wptrand the read pointer rptr does not reach the threshold (e.g., wptr!=rptr−1), the write controller 202 can continue or resume writing dataof the video bitstream into the bitstream buffer 136 (step 408). In thisexample, the threshold is equal to a step size of incrementing the writepointer wptr. However, this is for illustrative purposes only, and isnot meant to be a limitation of the present invention.

When the distance between the write pointer wptr and the read pointerrptr reaches the threshold (e.g., wptr==rptr−1), meaning that the writepointer wptr will catch up the read pointer rptr soon, the writecontroller 202 stops writing data of the video bitstream into thebitstream buffer 136 (step 406). In this way, the racing-mode ringbuffer access control scheme prevents the audio/video demultiplexingcircuit 126 from overwriting encoded video data that is not processed bythe video decoder 128 yet. The write controller 202 does not resumewriting data of the video bitstream into the bitstream buffer 136 untilthe video decoder 128 updates the read pointer rptr to a new value.Hence, when the distance between the write pointer wptr and the readpointer rptr does not reach the threshold (e.g., wptr !=rptr−1) due tothe read pointer rptr updated to a new value under a condition thatwriting data of the video bitstream into the bitstream buffer 136 ispaused, the write controller 202 resumes writing data of the videobitstream into the bitstream buffer 136 (steps 404 and 408).

At step 408, the write controller 202 updates the write pointer wptr tomove the write pointer wptr for writing data of the video bitstream intoa next write address of the bitstream buffer 136. For example, the writecontroller 202 updates the write pointer wptr according to the followingpseudo code.

  if (wptr==v_end)  wptr = v_start else  wptr = wptr+1

After data of the video bitstream is written into the bitstream buffer136 according to the updated write pointer wptr, the write controller202 checks if there are more data needed to be stored into the bitstreambuffer 136 (step 410). When there is no data needed to be stored intothe bitstream buffer 136, the write operation is ended. Otherwise, thecontrol flow proceeds with step 404.

FIG. 5 is a flowchart illustrating a method of controlling a readoperation of the bitstream buffer 136 according to an embodiment of thepresent invention. Provided that the result is substantially the same,the steps are not required to be executed in the exact order shown inFIG. 5. The method shown in FIG. 5 may be employed by the readcontroller 204. At step 502, the read controller 204 checks if the startpoint position is between the top address v_start and the bottom addressv_end. As mentioned above, a start point is indicative of a startaddress of a video bitstream stored in the bitstream buffer 136 that isa ring buffer. The racing-mode ring buffer access control scheme is onlyactive when the start point position is between the top address v_startand the bottom address v_end. Hence, the control flow proceeds with step504 when the start point position is between the top address v_start andthe bottom address v_end.

At step 504, the read controller 204 compares its read pointer rptr withthe received write pointer wptr to check if the read pointer rptr doesnot catch up the write pointer wptr (e.g., rptr !=wptr). When the readpointer rptr does not catch up the write pointer wptr (e.g., rptr!=wptr), the read controller 204 can continue or resume reading data ofthe video bitstream from the bitstream buffer 136 (step 508).

However, when the read point rptr catches up the write pointer wptr(e.g., rptr==wptr), the read controller 204 stops reading data of thevideo bitstream from the bitstream buffer 136 (step 506). In this way,the racing-mode ring buffer access control scheme prevents the videodecoder 128 from retrieving wrong encoded video data from the bitstreambuffer 136. The read controller 204 does not resume reading data of thevideo bitstream from the bitstream buffer 136 until the audio/videodemultiplexing circuit 126 updates the write pointer wptr to a newvalue. Hence, when the read pointer rptr does not catch up the writepointer wptr (e.g., rptr !=wptr) due to the write pointer wptr updatedto a new value under a condition that reading data of the videobitstream from the bitstream buffer 136 is paused, the read controller204 resumes reading data of the video bitstream from the bitstreambuffer 136 (steps 504 and 508).

At step 508, the read controller 204 calculates a read length whichindicates an amount of data still waiting to be fetched from thebitstream buffer 136 to the video decoder 128 for further processing.For example, the read controller 204 calculates the read lengthaccording to the following pseudo code.

  if (wptr < rptr)  length = (v_end-rptr) + (wptr-v_start) else  length= wptr-rptr

At step 510, the read controller 204 updates the read pointer rptr tomove the read pointer rptr for reading data of the video bitstream froma next read address of the bitstream buffer 136. For example, the readcontroller 204 updates the read pointer rptr according to the followingpseudo code.

  if (rptr==v_end)  rptr = v_start else  rptr = rptr+1

After data of the video bitstream is read from the bitstream buffer 136according to the updated read pointer rptr, the read controller 204checks if the frame decode operation is finished (step 512). When theframe decode operation is finished, the read operation is ended.Otherwise, the control flow proceeds with step 504.

FIG. 6 is a diagram illustrating a second video processing systemaccording to an embodiment of the present invention. The videoprocessing system 600 may be a part of the video receiving system 120shown in FIG. 1. In this embodiment, the video processing system 600includes the video decoder 128, the display engine 130, the displaycontrol circuit 132, and the display buffer 138. In addition, thedisplay buffer 138 is implemented using a ring buffer as shown in FIG.7. A racing-mode ring buffer access control scheme is employed toprevent the video decoder 138 from overwriting buffered pixel data thatis not used by the display engine 130 for video playback yet.

As shown in FIG. 7, the display buffer 138 is a ring buffer having a topaddress Buf_start and a bottom address Buf_end. In one embodiment, thetop address Buf_start and the bottom address Buf_end may be physicaladdresses that define a continuous physical storage space. In anotherembodiment, the top address Buf_start and the bottom address Buf_end maybe virtual addresses that define a continuous logical storage space.Hence, the total display buffer size is equal to (Buf_start−Buf_end).For example, the total display buffer size may be equal to an amount ofpixel data of n (n≧2) coding block rows, where each coding blockcontains m (m≧1) pixel lines. A coding block is a basic processing unitof a video coding standard. For example, when the video coding standardis H.264, one coding block is one macroblock (MB). For another example,when the video coding standard is VP9, one coding block is one superblock (SB). For yet another example, when the video coding standard isHEVC (High Efficiency Video Coding), one coding block is one coding treeunit (CTU).

Since the display buffer 138 is a ring buffer, the display buffer 138can be accessed (read/written) in a direction from the top addressBuf_start to the bottom address Buf_end and then rolling back to the topaddress Buf_start from the bottom address Buf_end.

During video decoding of one video frame, the video decoder 128 writespixel data of a reconstructed video frame into the display buffer 138,such that a write address of the pixel data moves downwards. When thewrite address reaches the bottom address Buf_end, the write address willroll back to the top address Buf_start, such that writing pixel data ofthe reconstructed video frame into the display buffer 138 continuesseamlessly.

During video playback of a reconstructed video frame, the display engine130 reads pixel data of the reconstructed video frame from the displaybuffer 138, such that a read address of the pixel data moves downwards.When the read address reaches the bottom address Buf_end, the readaddress will roll back to the top address Buf_start, such that readingpixel data of the reconstructed video frame from the display buffer 138continues seamlessly.

After an old data segment stored in the display buffer 138 is read andprocessed by the display engine 130, a storage area which buffers theold data segment can be reused to buffer a new data segment generatedfrom the video decoder 128. In addition, after the old data segment(which has been read and processed by the display engine 130) isoverwritten by the new data segment generated from the video decoder128, the storage area can be read by the display engine 130 again toobtain the new data segment. The video playback of a video frame is notstarted unless some pixel data of the video frame are already availablein the display buffer 138. Due to inherent characteristics of the ringbuffer, the write address chases the read address. To achieve smoothvideo playback, a read operation of the display buffer 138 cannot bepaused. Hence, a racing mode between the read operation and the writeoperation may be employed to control the write operation of the displaybuffer 138 that is a ring buffer. In accordance with the racing-modering buffer access control scheme, the video decoder 128 is configuredto include a reconstructed line counter 602 which maintains areconstructed line count value R_Line indicative of the number of pixellines that are reconstructed by the video decoder 128, and the displayengine 130 is configured to include a displayed line counter 604 whichmaintains a displayed line count value D_Line indicative of the numberof pixel lines that are displayed on the display device 140 through thedisplay engine 130.

In this embodiment, the video decoder 126 is arranged to performblock-based decoding, and the display engine 130 is arranged to performscan line based displaying. Hence, the reconstructed line counter 602increases the reconstructed line count value R_Line by a first incrementvalue (e.g., a value equal to a height of one coding block) each timeone coding block row (e.g., MB row, SB row, or CTU row) is completelydecoded. For example, assuming that one coding block has N pixels in acolumn direction, the reconstructed line count value R_Line is updatedby R_Line+N when one coding block row is completely decoded. Inaddition, the displayed line counter 604 increases the displayed linecount value D_Line by a second increment value (e.g., “1”) each time onepixel line is completely displayed. For example, the displayed linecount value D_Line is updated by D_Line+1 when one pixel line iscompletely displayed.

FIG. 8 is a flowchart illustrating a display control method according toan embodiment of the present invention. Provided that the result issubstantially the same, the steps are not required to be executed in theexact order shown in FIG. 8. The method shown in FIG. 8 may be employedby the display controller 132. In this example, the video decoder 128updates the reconstructed line count value R_Line to the display controlcircuit 132, and the display engine 130 updates the displayed line countvalue D_Line to the display control circuit 132. Hence, the displaycontrol circuit 132 can refer to the reconstructed line count valueR_Line to know the decoding status of a current video frame, and canrefer to the displayed line count value D_Line to know the displaystatus of the current video frame. Initially, the display controlcircuit 132 compares the reconstructed line count value R_Line and thedisplayed line count value D_Line to determine if video playback of areconstructed video frame can be started. When R_Line≧D_Line, thedisplay control circuit 132 assigns a frame base address ADDR to thedisplay engine (step 802), where the frame base address is indicative ofa start address of the reconstructed video frame stored in the displaybuffer 138 by the video decoder 128.

At step 804, the display control circuit 132 compares the reconstructedline count value R_Line and the displayed line count value D_Line todetermine if the write operation of the display buffer 138 should bestopped. In this example, the display control circuit 132 checks if adistance between the reconstructed line count value R_Line and thedisplayed line count value D_Line does not reach a threshold (e.g.,R_Line !=D_Line+k), where the threshold k may be set by any positiveinteger value, depending upon the actual design considerations. When thedistance between the reconstructed line count value R_Line and thedisplayed line count value D_Line does not reach the threshold (e.g.,R_Line !=D_Line+k), the display control circuit 132 does not assert acontrol signal S_(ctrl) for instructing the video decoder 128 to stopwriting pixel data of the reconstructed video frame into the displaybuffer 138. Next, the flow proceeds with step 810, such that the displayengine 130 continues reading pixel data of the reconstructed video framefrom the display buffer 138 and driving the display device 140 todisplay the pixel data of the reconstructed video frame. Hence, at step810, one pixel line is displayed on the display device 140 through thedisplay engine 130, and the displayed line counter 604 updates thedisplayed line count value D_Line (e.g., D_Line=D_Line+1)correspondingly.

However, when the distance between the reconstructed line count valueR_Line and the displayed line count value D_Line reaches the threshold(e.g., R_Line==D_Line+k), meaning that the video decoding speed is muchfaster than the video playback speed, the display control circuit 132asserts the control signal S_(ctrl) for instructing the video decoder128 to stop writing pixel data of the reconstructed video frame into thedisplay buffer 138 (step 806). In this way, the racing-mode ring bufferaccess control scheme prevents the video decoder 128 from overwritingpixel data that is not processed by the display engine 130 for videoplayback yet. As mentioned above, a read operation of the display buffer138 cannot be paused for achieving smooth video playback. Next, the flowproceeds with step 808, such that the display engine 130 continuesreading pixel data of the reconstructed video frame from the displaybuffer 138 and driving the display device 140 to display the pixel dataof the reconstructed video frame. Similarly, at step 808, the displayedline counter 604 updates the displayed line count value D_Line (e.g.,D_Line=D_Line+1) correspondingly.

The display control circuit 132 does not instruct the video decoder 128to resume writing pixel data of the reconstructed video frame into thedisplay buffer 138 until the display engine 130 (particularly, thedisplayed line counter 604) updates the displayed line count valueD_Line to a new value. Hence, when the distance between thereconstructed line count value R_Line and the displayed line count valueD_Line does not reach the threshold (e.g., R_Line !=D_Line+k) due to thedisplayed line count value D_Line updated to a new value under acondition that writing pixel data of the reconstructed video frame intothe display buffer 138 is paused, the display control circuit 132de-asserts the control signal S_(ctrl) for instructing the video decoder128 to resume writing pixel data of the reconstructed video frame intothe display buffer 138 (steps 804 and 810).

At step 812, the display control circuit 132 checks if there are morepixel lines needed to be displayed. When no pixel line is needed to bedisplayed, the display control operation is ended. Otherwise, thecontrol flow proceeds with step 804.

FIG. 9 is a diagram illustrating a third video processing systemaccording to an embodiment of the present invention. The videoprocessing system 900 may be a part of the video receiving system 120shown in FIG. 1. In this embodiment, the video processing system 900includes the receiving circuit 122, the audio/video demultiplexingcircuit 126, and the data buffer 134. In addition, the data buffer 134is implemented using a ring buffer as shown in FIG. 10. Further, aracing-mode ring buffer access control scheme is employed to prevent theaudio/video demultiplexing circuit 126 from retrieving wrong data fromthe ring buffer (i.e., data buffer 134), and prevent the receivingcircuit 122 from overwriting buffered data that is not processed by theaudio/video demultiplexing circuit 126 yet.

In one exemplary design, the communication link 110 shown in FIG. 1 maybe a wireless communication link. Hence, the receiving circuit 122 isused to receive the packets from the wireless communication link. Forexample, the receiving circuit 122 may be a Wireless Fidelity (WiFi)receiver. However, this is for illustrative purposes only, and is notmeant to be a limitation of the present invention.

In another exemplary design, the communication link 110 shown in FIG. 1may be a wired communication link. Hence, the receiving circuit 122 isused to receive the packets from the wired communication link. Forexample, the receiving circuit 122 may be a Universal Serial Bus (USB)receiver or a High-Definition Multimedia Interface (HDMI) receiver.However, this is for illustrative purposes only, and is not meant to bea limitation of the present invention.

As shown in FIG. 10, the data buffer 134 is a ring buffer having a topaddress v_start and a bottom address v_end. In one embodiment, the topaddress v_start and the bottom address v_end may be physical addressesthat define a continuous physical storage space. In another embodiment,the top address v_start and the bottom address v_end may be virtualaddresses that define a continuous logical storage space. Hence, thetotal data buffer size is equal to (v_start−v_end). The data buffer 134can be accessed (read/written) in a direction from the top addressv_start to the bottom address v_end and then rolling back to the topaddress v_start from the bottom address v_end.

During packet receiving of one video frame, the receiving circuit 122writes payload data of the packets into the data buffer 134, such that awrite pointer wptr (which is indicative of a current write address ofwriting payload data of the packets into the data buffer 134) movesdownwards. Specifically, the receiving circuit 122 receives a packetfrom the communication link 110, and unpacks the received packet towrite payload data included in the received packet into the data buffer134. Hence, the receiving circuit 122 updates the write pointer wptraccording to the number of packets received and the size of payload dataincluded in each packet received. When the write pointer wptr reachesthe bottom address v_end, the write pointer wptr will roll back to thetop address v_start, such that writing payload data of the packets intothe data buffer 134 continues seamlessly.

During audio/video demultiplexing of an input data (which includespayload data of at least one of the packets) of one video frame, theaudio/video demultiplexing circuit 126 reads the input data from thedata buffer 134, such that a read pointer rptr (which is indicative of acurrent read address of reading the input data from the data buffer 134)moves downwards. When the read pointer rptr reaches the bottom addressv_end, the read pointer wptr will roll back to the top address v_start,such that reading the input data from the data buffer 134 continuesseamlessly.

After an old data segment stored in the data buffer 134 is read andprocessed by the audio/video demultiplexing circuit 126, a storage areawhich buffers the old data segment can be reused to buffer a new datasegment generated from the receiving circuit 122. In addition, after theold data segment (which has been read and processed by the audio/videodemultiplexing circuit 126) is overwritten by the new data segmentgenerated from the receiving circuit 122, the storage area can be readby the audio/video demultiplexing circuit 126 again to obtain the newdata segment. Due to inherent characteristics of the ring buffer, thewrite pointer wptr chases the read pointer rptr, and the read pointerrptr also chases the write pointer wptr. A racing mode between the readpointer rptr and the write pointer wptr may be employed to controlaccess (read/write) of the data buffer 134 that is a ring buffer. Inaccordance with the racing-mode ring buffer access control scheme, theaudio/video demultiplexing circuit 126 is configured to include a writecontroller 902 which updates the write pointer wptr to the audio/videodemultiplexing circuit 126, and the audio/video demultiplexing circuit126 is configured to include a read controller 904 which updates theread pointer rptr to the receiving circuit 122.

FIG. 11 is a flowchart illustrating a method of controlling a writeoperation of the data buffer 134 according to an embodiment of thepresent invention. Provided that the result is substantially the same,the steps are not required to be executed in the exact order shown inFIG. 11. The method shown in FIG. 11 may be employed by the writecontroller 902. At step 1102, the write controller 902 sets an initialstart point position, wherein a start point is indicative of a startaddress of payload data stored in the data buffer 134 by the receivingcircuit 122. Since the data buffer 134 is a ring buffer, the initialstart point position is set by an address between the top addressv_start and the bottom address v_end. In addition, at the beginning ofwriting payload data of the packets into the data buffer 134, a firstdata segment of the payload data is written into a memory word addressedby a write address that is the initial start point position.

At step 1104, the write controller 902 compares its write pointer wptrwith the received read pointer rptr to check if a distance between thewrite pointer wptr and the read pointer rptr does not reach a threshold(e.g., wptr !=rptr−1). When the distance between the write pointer wptrand the read pointer rptr does not reach the threshold (e.g., wptr!=rptr−1), the write controller 902 can continue or resume writingpayload data of the packets into the data buffer 134 (step 1108). Inthis example, the threshold is equal to a step size of incrementing thewrite pointer wptr. However, this is for illustrative purposes only, andis not meant to be a limitation of the present invention.

However, when the distance between the write pointer wptr and the readpointer rptr reaches the threshold (e.g., wptr==rptr−1), meaning thatthe write pointer wptr will catch up the read pointer rptr soon, thewrite controller 902 stops writing payload data of the packets into thedata buffer 134 (step 1106). In this way, the racing-mode ring bufferaccess control scheme prevents the receiving circuit 122 fromoverwriting payload data that is not processed by the audio/videodemultiplexing circuit 126 yet. The write controller 902 does not resumewriting payload data of the packets into the data buffer 134 until theaudio/video demultiplexing circuit 126 updates the read pointer rptr toa new value. Hence, when the distance between the write pointer wptr andthe read pointer rptr does not reach the threshold (e.g., wptr !=rptr−1)due to the read pointer rptr updated to a new value under a conditionthat writing payload data of the packets into the data buffer 134 ispaused, the write controller 902 resumes writing data of the videobitstream into the data buffer 134 (steps 1104 and 1108).

At step 1108, the write controller 902 updates the write pointer wptr tomove the write pointer wptr for writing data of the video bitstream intoa next write address of the data buffer 134. For example, the writecontroller 902 updates the write pointer wptr according to the followingpseudo code.

  if (wptr==v_end)  wptr = v_start else  wptr = wptr+1

After payload data is written into the bitstream buffer 136 according tothe updated write pointer wptr, the write controller 902 checks if thereare more data needed to be stored into the data buffer 134 (step 1110).When there is no data needed to be stored into the data buffer 134, thewrite operation is ended. Otherwise, the control flow proceeds with step1104.

FIG. 12 is a flowchart illustrating a method of controlling a readoperation of the data buffer 134 according to an embodiment of thepresent invention. Provided that the result is substantially the same,the steps are not required to be executed in the exact order shown inFIG. 12. The method shown in FIG. 12 may be employed by the readcontroller 904. At step 1202, the read controller 904 checks if thestart point position is between the top address v_start and the bottomaddress v_end. As mentioned above, a start point is indicative of astart address of payload data stored in the data buffer 134 that is aring buffer. The racing-mode ring buffer access control scheme is onlyactive when the start point position is between the top address v_startand the bottom address v_end. Hence, the control flow proceeds with step1204 when the start point position is between the top address v_startand the bottom address v_end.

At step 1204, the read controller 904 compares its read pointer rptrwith the received write pointer wptr to check if the read pointer rptrdoes not catch up the write pointer wptr (e.g., rptr !=wptr). When theread pointer rptr does not catch up the write pointer wptr (e.g., rptr!=wptr), the read controller 204 can continue or resume reading payloaddata of the packets from the data buffer 134 (step 1208).

However, when the read point rptr catches up the write pointer wptr(e.g., rptr==wptr), the read controller 904 stops reading payload dataof the packets from the data buffer 134 (step 1206). In this way, theracing-mode ring buffer access control scheme prevents the audio/videodemultiplexing circuit 126 from retrieving wrong payload data from thedata buffer 134. The read controller 904 does not resume reading payloaddata of the packets from the data buffer 134 until the receiving circuit122 updates the write pointer wptr to a new value. Hence, when the readpointer rptr does not catch up the write pointer wptr (e.g., rptr!=wptr) due to the write pointer wptr updated to a new value under acondition that reading payload data of the packets from the data buffer134 is paused, the read controller 904 resumes reading payload data ofthe packets from the data buffer 134 (steps 1204 and 1208).

At step 1208, the read controller 204 calculates a read length whichindicates an amount of data still waiting to be fetched from the databuffer 134 to the audio/video demultiplexing circuit 126 for furtherprocessing. For example, the read controller 904 calculates the readlength according to the following pseudo code.

  if (wptr < rptr)  length = (v_end-rptr) + (wptr-v_start) else  length= wptr-rptr

At step 1210, the read controller 904 updates the read pointer rptr tomove the read pointer rptr for reading payload data of the packets froma next read address of the data buffer 134. For example, the readcontroller 904 updates the read pointer rptr according to the followingpseudo code.

  if (rptr==v_end)  rptr = v_start else  rptr = rptr+1

After payload data is read from the data buffer 134 according to theupdated read pointer rptr, the read controller 904 checks if the frameaudio/video demultiplexing operation is finished (step 1212). When theframe audio/video demultiplexing operation is finished, the readoperation is ended. Otherwise, the control flow proceeds with step 1204.

To achieve smooth video playback, a read operation of the display buffer138 cannot be paused. However, due to certain factors, it is possiblethat the video decoder 128 is unable to provide some pixel data of onereconstructed video frame in time. For example, the decoding speedbecomes unstable because of the bandwidth variation of the communicationlink (e.g., a wired communication link or a wireless communication link)110 between the video transmission system. 100 and the video receivingsystem 120. When the reconstructed pixel data of a portion of areconstructed video frame are not ready at the time the display engine130 starts driving the display device 140 to display the portion of thereconstructed video frame, a broken picture may be displayed on thedisplay device 140, thus resulting in a poor video quality. To preventthe display device 140 from displaying a broken picture, the presentinvention further proposes a frame base address switching scheme.

Please refer to FIG. 6 in conjunction with FIG. 13. FIG. 13 is a diagramillustrating a frame base address switching circuit according to anembodiment of the present invention. The frame base address switchingcircuit 1302 is apart of the display control circuit 132 shown in FIG. 1and FIG. 6. As mentioned above, the display buffer 138 is used to bufferpixel data of a reconstructed frame (which is a current frame beingdecoded), and the reference frame buffer 139 is used to buffer one ormore reference frames (which are previous frames already decoded). Inthis embodiment, the frame base address switching circuit 1302 may beimplemented using a multiplexer having a first input port used toreceive a reconstructed frame base address, a second input port used toreceive a reference frame base address, and an output port used toselectively output the reconstructed frame base address or the referenceframe base address as the frame base address ADDR used by the displayengine 130. As shown in FIG. 13, the frame base address switchingcircuit 1302 is controlled by a result of comparing the reconstructedline count value R_Line maintained by the reconstructed line counter 602and the displayed line count value D_Line maintained by the displayedline counter 604. When the reconstructed line count value R_Line issmaller than the displayed line count value D_Line, meaning that thevideo decoder 128 fails to provide the needed pixel line data in time,the frame base address switching circuit 1302 selects the referenceframe base address as the frame base address ADDR. When thereconstructed line count value R_Line is not smaller than the displayedline count value D_Line, meaning that the video decoder 128 can providethe needed pixel line data in time, the frame base address switchingcircuit 1302 selects the reconstructed frame base address as the framebase address ADDR.

The reconstructed frame base address is indicative of a start address ofa reconstructed video frame (which is a current frame being decoded)stored in the display buffer 138. The reference frame base address isindicative of a start address of a reference video frame (which is aprevious frame already decoded) stored in the reference frame buffer139. As shown in FIG. 6, the frame base address ADDR is supplied fromthe display control circuit 132 to the display engine 130. When theframe base address ADDR is set by the reconstructed frame base address,the display engine 130 fetches pixel data of a reconstructed video frame(which is a current frame being decoded) from the display buffer 138according to the frame base address ADDR, and drives the display device140 according to the pixel data of the reconstructed video frame (whichis a current frame being decoded). When the frame base address ADDR isset by the reference frame base address, the display engine 130 fetchespixel data of a reference frame (which is a previous frame alreadydecoded) from the reference frame buffer 139 according to the frame baseaddress ADDR, and drives the display device 140 according to the pixeldata of the reference frame (which is a previous frame already decoded).

When the decoding speed is stable during video playback of the whole ofa current video frame, the display device 140 will display the currentvideo frame completely. However, when the decoding speed is only stableduring video playback of a portion of a current video frame, the displaydevice 140 displays the portion of the current video frame and furtherdisplays a portion of a previous video frame. FIG. 14 is a diagramillustrating a video frame displayed on the display device 140 accordingto an embodiment of the present invention. The displayed video frame IMGis composed of a partial reconstructed frame and a partial referenceframe. Before the reconstructed line count value R_Line becomes smallerthan the displayed line count value D_Line, pixel data of areconstructed video frame (which is a current frame being decoded) aredisplayed on a first region of the display device 140 through thedisplay engine 130 using the frame base address ADDR set by thereconstructed frame base address. After the reconstructed line countvalue R_Line becomes smaller than the displayed line count value D_Line,pixel data of a reference frame (which is a previous frame alreadydecoded) are displayed on a second region of the display device 140through the display engine 130 using the frame base address ADDR set bythe reference frame base address. With the help of automaticallyswitching from the reconstructed frame base address to the referenceframe base address, no broken picture is displayed on the display device140 when the decoding speed is unstable due to the bandwidth variationbetween the video transmitting system 100 and the video receiving system120.

Those skilled in the art will readily observe that numerousmodifications and alterations of the device and method may be made whileretaining the teachings of the invention. Accordingly, the abovedisclosure should be construed as limited only by the metes and boundsof the appended claims.

What is claimed is:
 1. A video processing system comprising: a storagedevice, comprising: a bitstream buffer, wherein the bitstream buffer isa ring buffer; an audio/video demultiplexing circuit, arranged toreceive an input data, and perform an audio/video demultiplexingoperation upon the input data to write data of a video bitstream intothe ring buffer; and a video decoder, arranged to fetch data of thevideo bitstream from the ring buffer, and perform a video decodingoperation upon the fetched data of the video bitstream.
 2. The videoprocessing system of claim 1, wherein the audio/video demultiplexingcircuit is further arranged to update a write pointer to the videodecoder, where the write pointer is indicative of a current writeaddress of writing data of the video bitstream into the ring buffer bythe audio/video demultiplexing circuit; and the video decoder comprises:a read controller, arranged to compare the write pointer with a readpointer, and stop fetching data of the video bitstream from the ringbuffer when the read pointer catches up the write pointer, where theread pointer is indicative of a current read address of fetching data ofthe video bitstream from the ring buffer by the video decoder.
 3. Thevideo processing system of claim 2, wherein the read controller does notresume fetching data of the video bitstream from the ring buffer untilthe audio/video demultiplexing circuit updates the write pointer to anew value.
 4. The video processing system of claim 1, wherein the videodecoder is further arranged to update a read pointer to the audio/videodemultiplexing circuit, where the read pointer is indicative of acurrent read address of fetching data of the video bitstream from thering buffer by the video decoder; and the audio/video demultiplexingcircuit comprises: a write controller, arranged to compare the readpointer with a write pointer, and stop writing data of the videobitstream into the ring buffer when a distance between the write pointerand the read pointer reaches a threshold, where the write pointer isindicative of a current write address of writing data of the videobitstream into the ring buffer by the audio/video demultiplexingcircuit.
 5. The video processing system of claim 4, wherein the writecontroller stops writing data of the video bitstream into the ringbuffer when the write pointer lags behind the read pointer by thethreshold that is equal to a unit increment of the write pointer.
 6. Thevideo processing system of claim 4, wherein the write controller doesnot resume writing data of the video bitstream into the ring bufferuntil the video decoder updates the read pointer to a new value.
 7. Avideo processing system comprising: a storage device, comprising: adisplay buffer, wherein the display buffer is a ring buffer; a videodecoder, arranged to perform a video decoding operation upon data of avideo bitstream to write pixel data of a reconstructed video frame intothe ring buffer; and a display engine, arranged to fetch pixel data ofthe reconstructed video frame from the ring buffer, and drive a displaydevice according to the fetched pixel data of the reconstructed videoframe.
 8. The video processing system of claim 7, wherein the videodecoder comprises a first counter arranged to maintain a first countvalue indicative of a number of pixel lines that are reconstructed bythe video decoder; the display engine comprises a second counterarranged to maintain a second count value indicative of a number ofpixel lines that are displayed on the display device through the displayengine; and the video processing system further comprises: a displaycontrol circuit, arranged to receive the first count value from thevideo decoder, receive the second count value from the display engine,and refer to the first count value and the second first count value tocontrol the display engine.
 9. The video processing system of claim 8,wherein the display control circuit is further arranged to compare thefirst count value with the second count value, and instruct the videodecoder to stop writing pixel data of the reconstructed video frame intothe ring buffer when a distance between the first count value and thesecond count value reaches a threshold.
 10. The video processing systemof claim 9, wherein the display control circuit does not instruct thevideo decoder to resume writing pixel data of the reconstructed videoframe into the ring buffer until the second count value is updated to anew value.
 11. A video processing system comprising: a storage device,comprising: a data buffer, wherein the data buffer is a ring buffer; areceiving circuit, arranged to receive packets and unpack the packets towrite payload data of the packets into the ring buffer; and anaudio/video demultiplexing circuit, arranged to fetch an input data fromthe ring buffer, and perform an audio/video demultiplexing operationupon the fetched input data, wherein the fetched input data comprisepayload data of at least one of the packets.
 12. The video processingsystem of claim 11, wherein the receiving circuit is further arranged toupdate a write pointer to the audio/video demultiplexing circuit, wherethe write pointer is indicative of a current write address of writingpayload data into the ring buffer by the receiving circuit; and theaudio/video demultiplexing circuit comprises: a read controller,arranged to compare the write pointer with a read pointer, and stopfetching payload data from the ring buffer when the read pointer catchesup the write pointer, where the read pointer is indicative of a currentread address of fetching payload data from the ring buffer by theaudio/video demultiplexing circuit.
 13. The video processing system ofclaim 12, wherein the read controller does not resume fetching payloaddata from the ring buffer until the receiving circuit updates the writepointer to a new value.
 14. The video processing system of claim 11,wherein the audio/video demultiplexing circuit is further arranged toupdate a read pointer to the receiving circuit, where the read pointeris indicative of a current read address of fetching payload data fromthe ring buffer by the audio/video demultiplexing circuit; and thereceiving circuit comprises: a write controller, arranged to compare theread pointer with a write pointer, and stop writing payload data intothe ring buffer when a distance between the write pointer and the readpointer reaches a threshold, where the write pointer is indicative of acurrent write address of writing payload data into the ring buffer bythe receiving circuit.
 15. The video processing system of claim 14,wherein the write controller stops writing payload data into the ringbuffer when the write pointer lags behind the read pointer by thethreshold that is equal to a unit increment of the write pointer. 16.The video processing system of claim 14, wherein the write controllerdoes not resume writing payload data into the ring buffer until theaudio/video demultiplexing circuit updates the read pointer to a newvalue.
 17. The video processing system of claim 11, wherein thereceiving circuit receives the packets transmitted via a wirelesscommunication link.
 18. The video processing system of claim 17, whereinthe receiving circuit is a Wireless Fidelity (WiFi) receiver.
 19. Thevideo processing system of claim 11, wherein the receiving circuitreceives the packets transmitted via a wired communication link.
 20. Thevideo processing system of claim 19, wherein the receiving circuit is aUniversal Serial Bus (USB) receiver or a High-Definition MultimediaInterface (HDMI) receiver.